Some software compilers provide built-in versions of certain functions in a corresponding software library. For example, the GNU Compiler Collection (GCC), wherein the name “GNU” is a recursive acronym for “GNU's Not Unix!”, provides built-in versions of functions in the high level C software programming language standard library. That is, the implementations of the functions are written into a compiled object file, or executable file, and the program calls the built-in versions of the functions when it is executed.
A compiler may use a built-in version of a library to provide the functionality included in the high-level language source code program being compiled when there is no corresponding set of machine instructions supported by the CPU for which the program is being compiled for execution. For example, floating point operations and 64-bit integer operations may not be supported on many mobile devices. As a specific example, an ARMv5 processor, developed by ARM Holdings plc, does not include hardware floating point operations in its instruction set architecture (ISA), so compiler built-in helper functions are provided by the compiler to support floating point operations. However, another CPU, for example, the ARMv7 processor, also developed by ARM Holding plc, may include hardware floating point operations in its instruction set architecture.
An important consideration is how to migrate an application software program compiled to run on one processor that lacks the machine instructions needed to implement certain of the application's operations, and that relies on compiler built-in helper functions to provide support for such functionality, to run as efficiently as possible on another, different, processor that includes machine instructions needed to implement these certain operations.
One prior art way to migrate the application software program is to recompile the source code for the application program for a different, target ISA to replace or remove the compiler built-in helper functions, but doing so necessarily requires access to the source code for the application program, and recompiling the program every time it is migrated to a different computing platform.
Another prior art way to migrate the application software program is using binary translation. Binary translation involves emulating one instruction set by another instruction set through translation of the object code for the application software program. Object code is also commonly referred to as binary code, or executable code, or a combination of the above. In binary translation, sequences of machine language instructions are translated from a source instruction set to a target instruction set. Translation can occur at static-time, that is, the entire sequence of machine language instructions in an executable file can be converted from the source instruction set into a target instruction set without having to first run, or execute, the code. Dynamic translation involves converting short sequences, or blocks, of machine language instructions in an executable file from the source instruction set into a target instruction set, as the blocks are encountered during run time.
If a source instruction set architecture (source ISA) does not include machine instructions that support a particular functionality provided in an application program, those portions of the application program that relate to the particular functionality may be converted into appropriate compiler built-in helper functions when the application program is compiled. If the target instruction set architecture (target ISA) does include machine instructions that support the particular functionality provided in the application program, it would be beneficial when performing a binary translation of the program from the source ISA to the target ISA to convert the compiler built-in helper functions to a sequence of one or more machine instructions based on the target ISA that support the particular functionality.